LLM 是无状态的，记忆才是 Agent 的灵魂

来源：htmlDecode("极客工具 XTool")

原文链接：https://mp.weixin.qq.com/s/4mMSHWZqQHvqb6SRHOgRtA

---

AI Agent 记忆系统全景：概念、架构与实现对比

引言

LLM 是无状态的。记忆，是让 Agent 从"工具"变成"伙伴"的关键桥梁。
但"记忆"这个词太笼统了。一个 Agent 到底需要记住什么？怎么存、怎么取、怎么淘汰？不同产品/框架给出的答案截然不同。
本文先建立 ** 统一的概念模型 ** （基于 CoALA 论文和 ACE 论文），再分别审视两大路线——个人 Agent 产品和开发框架，最后提炼可复用的设计模式。

理论基础

Agent 记忆系统的设计并非凭空而来，它有两条重要的理论脉络： ** 认知科学的记忆分类 ** （CoALA 论文）和 ** 上下文工程的工作流 ** （ACE 论文）。

CoALA 框架：认知科学映射

CoALA（CoALA 论文，arXiv 2309.02427）将认知科学的记忆分类系统地映射到语言智能体： 记忆类型 人类类比 Agent 含义 实践形态 ** 工作记忆 ** 当前注意力焦点 当前决策周期的活跃信息 上下文窗口 + Prompt 变量 ** 语义记忆 ** 在学校学到的知识 关于世界的事实（"用户偏好 Kotlin"） MEMORY.md / Store / 向量数据库 ** 情景记忆 ** 回忆过去的经历 过去行为的序列（"上次部署失败了"） 对话历史 / Few-shot 示例 ** 程序性记忆 ** 学会骑自行车 执行任务的能力（LLM 权重 + Agent 代码） System Prompt / Agent 代码
** 关键洞察 ** ： ** 语义记忆 ** 用于 ** 个性化 ** ——记住用户的事实，让每次交互都"懂你" ** 情景记忆 ** 用于 ** 复用经验 ** ——记住过去的成功/失败序列，指导新任务 ** 程序性记忆 ** 用于 ** 自我优化 ** ——修改自己的行为规则。但这在实践中风险最高（可能引入 bug 或偏离设计意图），因此多数系统以固定的 Prompt 和模型参数为主 ** 工作记忆是中枢枢纽 ** ——所有其他记忆类型的读写都经过工作记忆
** 场景选择指南 ** ：如果执行任务有"正确方法"（如客服 SOP），情景记忆（Few-shot 示例）更有效；如果执行任务没有固定方法（如创意写作），语义记忆（事实积累）更重要。

ACE 论文：三角色上下文工程

ACE（Agentic Context Engineering，arXiv 2510.04618）提出了一个三角色协作模型来管理 Agent 的上下文： 角色 职责 输出 ** 生成器（Generator） ** 根据当前上下文生成推理和行动 推理轨迹、工具调用、中间结果 ** 反思器（Reflector） ** 分析轨迹，提取成功/失败经验 战略洞察、失败模式、领域概念 ** 整理器（Curator） ** 将反思结果结构化，更新上下文 结构化条目，可确定性合并
** 这个模型的核心价值 ** ：把"记忆管理"从 Agent 的主任务中剥离出来，形成独立的生产线。不是边聊天边记笔记，而是有一个专门的角色负责"反思过去"，另一个负责"整理归档"。
** 与 Dreaming 的对应关系 ** ：OpenClaw 的 Dreaming 三阶段（Light → REM → Deep）本质上是 ACE 三角色在离线场景的实现——Light = Generator 的暂存排序，REM = Reflector 的主题反思，Deep = Curator 的结构化晋升。

RAG vs Memory：两个不同的问题

ACE 论文明确区分了 RAG 和 Memory： 维度 RAG Memory ** 解决什么问题 ** 广泛的知识检索 个性化交互历史 ** 信息来源 ** 大规模文档集合（政策、法规、技术文档） 用户多会话的交互数据 ** 信息密度 ** 密集、非结构化（长文本、表格） 稀疏、需要提炼（对话中的关键点） ** 检索方式 ** 关键词 + 向量检索 总结、压缩、图谱关系、时序演化 ** 关注指标 ** 召回率和精准度 相关性和时效性
** 知识层级 ** （从 ACE 论文）：

Global（通用知识）  → 已嵌入 LLM 基座模型
Org（组织知识）     → RAG，向量数据库检索
User（用户知识）    → Memory，这就是记忆不可或缺的地方

** 一句话总结 ** ：RAG 解决"我们知道什么"（专业），Memory 解决"我们记得什么"（贴心）。两者结合才能构建既专业又贴心的 AI 系统。

核心概念模型

Agent 记忆可以拆解为三个核心概念。它们之间的关系是： ** ChatHistory 是原材料，UserMemory 和 UserProfile 是加工品 ** 。

ChatHistory：原始对话记录

** 是什么 ** ：持久化存储用户的每个会话的对话记录。逐轮、逐条保存。对应 CoALA 的 ** 情景记忆 ** 。
** 特点 ** ： 原始、未加工，包含大量噪音（寒暄、纠错、重复表述） 是所有记忆的 ** 原材料 ** ——后续的 Memory、Profile 都从这里提取 短期记忆是  thread-scoped memory （当前会话），长期记忆是  cross-thread memory （跨会话）
** 为什么不能直接用 ** ：全量灌入上下文窗口会 token 爆炸，LLM 在长上下文中的表现也不理想（"注意力稀释"）。需要 ** 基于规则 ** 生成关联的摘要/压缩记忆，提取结构化的主体（画像标签）和事件。

UserMemory：用户个人笔记

** 是什么 ** ：从 ChatHistory 中提炼的 ** 精炼笔记 ** ——用户环境、约定、经验教训、待办事项。对应 CoALA 的 ** 语义记忆 ** 。
** 特点 ** ： 不是原始对话，而是 ** 加工后的知识 ** 体积小、密度高，可以直接注入 System Prompt 需要 ** 淘汰机制 ** ——取历史 memory 中最近的和重要的信息，过时的淘汰
** 典型内容 ** ： "用户偏好 Kotlin，不喜欢 Java" "上周部署失败，原因是端口冲突" "代码审查时团队要求 AOP 职责分离"

UserProfile：用户画像

** 是什么 ** ：关于用户的 ** 结构化事实 ** ——偏好、风格、习惯、个人背景。是语义记忆的子集，专门围绕用户建模。
** 特点 ** ： 相对稳定，变化频率低 可以是结构化的 JSON（Profile 模式），也可以是自由文本 用于个性化 Agent 的交互方式
** 典型内容 ** ： "职业：后端工程师，技术栈：Kotlin/Python" "沟通风格：简洁，不喜欢客套" "时区：UTC+8，语言：中文"

三者的关系

ChatHistory（原始对话）
    ↓ 基于规则提取/摘要
    ├→ UserMemory（用户个人笔记） ← 持续更新，淘汰过时内容
    └→ UserProfile（用户画像）     ← 低频更新，相对稳定

** 核心问题 ** ：ChatHistory 是原材料，UserMemory 和 UserProfile 是加工品。如何高效地从 ChatHistory 中提取出高质量的 UserMemory 和 UserProfile，是所有记忆系统要解决的核心问题。

User Memory vs Agent Memory

ACE 论文提出了一个重要的区分——记忆的服务对象不同： 维度 User Memory（用户记忆） Agent Memory（Agent 记忆） ** 记住谁 ** 记住用户 记住自己 ** 内容 ** 偏好、画像、关键事件 工作流、技能积累、错误日志 ** 目标 ** 个性化体验 优化工作流
** 实践中 ** ：Hermes 的 USER.md = User Memory，MEMORY.md = Agent Memory。OpenClaw 同理。两者共存但服务不同目标。

记忆的存储形态

形态 特点 典型方案 ** 基于会话 ** 只保留当前对话，不跨会话 内存上下文、Chat History ** 基于列表 ** 按时间顺序存储，简单直观 Mem0、LangGraph Memory ** 基于图谱 ** 节点+关系，支持复杂查询 Mem0 Graph、Zep、Neo4j ** 基于 Profile ** 围绕用户/实体组织，高度定制 Memobase、自定义方案

如何复用已有的 RAG 基础设施？

对于 ChatHistory 的检索，可以直接复用 RAG 管道： ** 分块存储 ** ：对话记录按轮次/时间窗口分块 ** 向量化 + 关键词索引 ** ：语义搜索 + BM25 混合检索 ** 元数据过滤 ** ：按  user_id 、 session_id 、 time_range  过滤 ** 按需召回 ** ：不是全量灌入，而是根据当前查询召回最相关的片段

Memory 的工作流程

无论哪个框架，记忆系统的核心工作流都可以归纳为三步：

Add Context → Process & Extract → Retrieve & Assemble

Step 1：Add Context — 输入信号

将以下信号实时送入记忆层： ** 对话消息 ** ：用户说的、Agent 回的 ** 业务数据 ** ：系统事件、工具调用结果、外部通知 ** 时间元数据 ** ：什么时候发生的

Step 2：Process & Extract — 加工提炼

这是记忆系统最核心的环节，不同框架的差异化主要在这里： 加工方式 说明 代表 ** LLM 提取 ** 每轮对话后用 LLM 判断"值得记住什么" ChatGPT save_memories、Hermes ** 自动摘要 ** 对话窗口滑动时，用 LLM 压缩早期内容 LangGraph SummarizationNode ** 知识图谱构建 ** 自动提取实体关系，维护时序知识图谱 Mem0、Hindsight ** 评分巩固 ** 多维度评分，反复验证后才晋升为长期记忆 OpenClaw Dreaming ** 滑动窗口 ** 简单保留最近 N 条，不做深度加工 Spring AI MessageWindow
** Graph RAG 模式 ** （Mem0 等采用的）：
自动从对话中提取实体和关系，维护一个 ** 时序知识图谱 ** ——不只是记住"用户喜欢披萨"，还知道这个偏好的时间线、变化过程、与其他事实的关联。

Step 3：Retrieve & Assemble — 检索与组装

在每次 Agent 回复前，从记忆层检索相关内容，组装成 LLM 可用的上下文： ** 按相关性检索 ** ：语义搜索 + 关键词搜索混合 ** 按时间衰减 ** ：旧记忆权重降低 ** 去重与多样性 ** ：MMR 等算法避免返回重复信息 ** 格式化输出 ** ：预格式化的、关系感知的上下文块，优化 LLM 理解

个人 Agent 产品

OpenClaw 和 Hermes 都是面向个人用户的 Agent 产品，它们的记忆设计面向同一个问题： ** 如何让一个长期陪伴的 Agent 越来越懂你？ **

OpenClaw：文件即记忆 + 自动巩固

** 核心理念 ** ：模型只记住写到磁盘的内容，没有隐藏状态。

记忆文件体系

MEMORY.md          ← 长期记忆（精炼笔记）
memory/YYYY-MM-DD.md  ← 每日日记（原始记录）
DREAMS.md          ← Dream 日记（审阅用）
SOUL.md / USER.md  ← 身份与用户画像

三层时间维度：当天日记 → 近期上下文 → 长期精炼。

Dreaming：自动记忆巩固

灵感来自人类睡眠的记忆巩固机制，三阶段处理：

Light（排序暂存）→ REM（主题反思）→ Deep（评分晋升）

Deep 阶段的六维评分：

Score = 0.30×Relevance + 0.24×Frequency + 0.15×QueryDiversity 
      + 0.15×Recency + 0.10×Consolidation + 0.06×ConceptRichness

** 三个门控 ** 同时通过才晋升： minScore + minRecallCount + minUniqueQueries 。
这意味着： ** 重要的事说三遍才记住 ** ——只有反复出现、被多次检索、与多个查询相关的信息才能进入长期记忆。

搜索增强

** 混合搜索 ** ：向量（语义）+ BM25（关键词）并行 ** Temporal Decay ** ：旧记忆权重降低（半衰期 30 天） ** MMR ** ：结果多样性去重 ** CJK 优化 ** ：中文三元组分词

Memory Wiki：结构化知识库层

不只是自由文本笔记，还有结构化的 Claims 体系：

text:"用户偏好 Kotlin"
status: active
confidence:0.95
evidence:
-"2026-04-18 对话中明确表示"
-"2026-04-20 代码审查中再次确认"

这让知识库从"被动笔记"升级为"信念层"——每个知识条目都有置信度和证据链。

Hermes：严格容量管理 + Provider 插件化

** 核心理念 ** ：记忆是有界的、精心维护的，不是无限堆叠的。

双文件架构 + 硬限制

文件 用途 硬限制 MEMORY.md Agent 个人笔记 2200字符 (~800 tokens) USER.md 用户画像 1375字符 (~500 tokens)
极其克制——不是"能存多少存多少"，而是"只留最值得留的"。

冻结快照模式

记忆在会话启动时注入 System Prompt， ** 整个会话期间不变 ** 。
** 深层动机 ** ：保护 LLM prefix cache——如果 System Prompt 每轮都变，前缀缓存失效，每次请求都要重新计算，成本和延迟都上升。

80% 容量阈值

超过 80% 时主动触发合并精简。不是被动淘汰，而是 ** 主动维护 ** 。

安全扫描

注入 System Prompt 前检测 prompt injection、凭据泄露、不可见 Unicode。这是其他框架都没有的安全层。

8 大外部 Provider

内置 8 种记忆后端，从零依赖到企业级： Provider 独特能力 适用场景 ** Honcho ** 辩证用户建模 + 多 Peer 多 Agent 用户建模 ** OpenViking ** L0/L1/L2 分层加载 结构化知识管理 ** Mem0 ** 服务端自动提取 + 去重 全自动零配置 ** Hindsight ** 知识图谱 + reflect 推理 企业级知识图谱 ** Holographic ** HRR 代数查询 + 矛盾检测 本地零依赖 ** RetainDB ** 7 种记忆类型 + Delta 压缩 类型丰富 ** ByteRover ** 压缩前提取 + CLI CLI 工作流 ** Supermemory ** 上下文围栏 + 多容器 多项目隔离

OpenClaw vs Hermes

维度 OpenClaw Hermes 记忆格式 自由文本文件 自由文本文件 容量管理 Dreaming 自动巩固 80% 硬限制 + 主动合并 会话内更新 ✅ 实时可更新 ❌ 冻结快照（保护 prefix cache） 自动巩固 ✅ 三阶段 Dreaming ❌ 需 Provider 提供 安全扫描 ❌ ✅ 注入/泄露检测 外部引擎 4 种后端 + memory-wiki 8 种 Provider 知识库层 ✅ memory-wiki（Claims + 仪表板） ❌

阿里云百炼记忆库

阿里云百炼在 2026 年推出了 ** 记忆库 ** 服务——目前主流云厂商中 ** 第一个将 Agent 记忆做成独立 PaaS 产品 ** 的。通过 REST API 直接调用，开箱即用。

核心架构

对话消息 → AddMemory API → 自动提取 → 记忆片段 + 用户画像
                                            ↓
新对话 ← SearchMemory API ← 语义检索 ← 注入 Prompt

** 两种记忆内容 ** ： 类型 对应概念 说明 举例 ** 记忆片段 ** Memory 从对话中自动提取的关键事件和信息 "用户要求每天上午9点发送日程提醒" ** 用户画像 ** Profile 基于自定义模板从对话中提取的结构化属性 年龄=28、职业=软件工程师、爱好=摄影

记忆规则系统（最值得借鉴的设计）

记忆库的核心创新在于 ** 可配置的记忆规则 ** ，而非硬编码的提取逻辑：
** 记忆片段规则 ** （每库最多 50 条）： ** 规则指令 ** ：定义提取策略，可选默认指令或自定义指令 ** 自动更新 ** ：开启后模型会自动更新已有记忆（合并/去重） ** 记忆过期时间 ** ：7天/30天/180天/永不过期
** 用户画像规则 ** （每库最多 50 条）： ** 画像字段 ** ：自定义要提取的属性（如"年龄""职业""爱好"） ** 描述 ** ：引导模型提取相关信息 ** 初始值 ** ：未提取到时使用的默认值
** 产品化启示 ** ：这种"规则模板"设计让非技术人员也能通过控制台配置记忆行为，而不需要写代码。这是从"开发者工具"到"产品能力"的关键跨越。

检索增强

SearchMemory 提供了四个检索增强开关： 开关 作用 推荐场景 ** 意图判别召回 ** 判断当前对话是否需要召回记忆 建议开启，避免无关检索 ** 查询改写 ** 优化口语化的查询 口语化输入时开启 ** 重排序 ** 对检索结果重排序 提升相关性 ** 相似度阈值 ** 过滤低相关结果 建议 0.5-0.7

完整 API 矩阵

API 方法 说明 AddMemory POST /add 添加记忆，支持对话和自定义内容 SearchMemory POST /memory_nodes/search 语义检索记忆 ListMemory GET /memory_nodes 分页列出记忆 UpdateMemory PATCH /memory_nodes/{id} 更新记忆内容 DeleteMemory DELETE /memory_nodes/{id} 删除记忆 CreateProfileSchema POST /profile_schemas 创建画像模板 GetUserProfile GET /profile_schemas/{id}/user_profile 获取用户画像

与本文概念模型的精确对应

本文概念 百炼记忆库实现 ** History ** 调用 AddMemory 时传入的 messages 数组 ** Memory ** 记忆片段（memory_nodes），自动从对话中提取 ** Profile ** 用户画像（profile_schema + user_profile），结构化属性

多租户与隔离

** 记忆库 ** ：独立的记忆管理容器，不同业务场景使用不同记忆库 ** 记忆实体 ID ** （user_id）：以用户维度隔离，不同用户的记忆互不干扰 ** 默认记忆库 ** ：每个账号自带，不可删除但可编辑 ** 限流 ** ：add 接口 120 QPM，search 接口 300 QPM

为什么值得产品化参考

百炼记忆库的设计有几个点特别适合智能体平台借鉴： ** 记忆规则模板化 ** ：不硬编码提取逻辑，而是让用户/开发者配置规则。同一个记忆服务可以服务不同业务场景 ** Memory + Profile 双通道 ** ：一个 API 调用同时提取记忆片段和用户画像，一次写入双倍产出 ** 检索增强开箱即用 ** ：意图判别、查询改写、重排序都做成可配置的开关 ** 过期时间可配置 ** ：不同类型的记忆有不同的时效性 ** meta_data 自定义 ** ：支持在记忆上附加自定义元数据，方便后续按元数据过滤

扣子（Coze）长期记忆

扣子是字节跳动旗下的 AI Bot 开发平台，其记忆系统 ** 面向非技术用户和低代码开发者 ** ，与阿里云百炼的 PaaS 定位形成互补。

三层记忆体系

层级 实现方式 生命周期 适用场景 ** 变量 ** Key-Value 键值对， {{变量名}}  引用 永久（用户维度） 用户偏好：姓名、语言、主题 ** 数据库 ** 结构化表格 + NL2SQL 永久（单用户/多用户模式） 记账、打卡、任务管理 ** 长期记忆 ** 自动提取用户画像 + 记忆点 永久（用户隔离） 情感陪伴、个性化推荐

长期记忆的两种内容

内容 说明 优先级 ** 用户画像 ** 个人资料和偏好（称呼、年龄、性别） 自动提取 ** 记忆点 ** 特定日期的关键事件（"昨天考试得了100分"） 自动提取 ** 用户编辑 ** 用户主动提供并手动编辑的信息 ** 最高 **

与本文概念模型的对应

本文概念 扣子实现 ** History ** 对话上下文（平台自动管理，不暴露给开发者） ** Memory ** 长期记忆的记忆点（自动提取） ** Profile ** 变量 + 长期记忆的用户画像

产品设计特点

** 零代码配置 ** ：在 Bot 配置页开启长期记忆即可，无需写任何代码 ** 工作流集成 ** ：工作流中提供「长期记忆写入」和「长期记忆召回」节点，可在编排中精细控制 ** NL2SQL ** ：用户用自然语言操作数据库，如"记录今天花了35元" ** 强制记忆 ** ：用户说"记住XXX"可触发强制记录，解决 Agent 不主动记录非关键信息的问题

产品化启示

扣子的设计代表了 ** 将记忆能力 C 端化 ** 的路线： 阿里云百炼 → 面向开发者，API + 规则模板 扣子 → 面向普通用户，开关 + 自然语言 两者共同点： ** 记忆提取自动化 ** ，用户不需要手动管理

开发框架

LangGraph、LlamaIndex 和 Spring AI 是面向开发者的框架，它们提供的不是"记忆产品"，而是 ** 构建记忆系统的基础设施 ** 。

LangGraph：Checkpointer + Store 双层存储

** 核心设计 ** ：短期记忆是状态（State），长期记忆是存储（Store）。

短期记忆：Checkpointer

thread-scoped 的对话历史持久化：

checkpointer = PostgresSaver.from_conn_string(DB_URI)
graph = builder.compile(checkpointer=checkpointer)

每个 thread 独立的 checkpoint 链，支持时间旅行（回滚到任意历史状态）。
** 管理策略 ** ： ** Trim ** ：保留最近 N 条（按 token 计数） ** Summarize ** ：LLM 摘要早期消息，替换原文 ** Delete ** ：主动删除特定消息

长期记忆：Store

跨 thread 的命名空间存储，支持语义搜索：

store.put(("user_123","preferences"),"food",{"text":"喜欢披萨"})
items = store.search(("user_123","preferences"), query="晚餐推荐")

** 命名空间 **  =  (userId, context)  元组，天然支持多用户隔离。

记忆写入时机

时机 优点 缺点 ** Hot Path ** （回复前实时写入） 实时，不丢信息 增加延迟，Agent 要多任务 ** Background ** （异步后台提取） 零延迟，专注回复 需要调度策略，可能延迟同步

生产后端

Postgres / MongoDB / Redis，覆盖主流数据库。

Mem0：通用记忆引擎

Mem0 是目前最活跃的开源 Agent 记忆框架（GitHub 25k+ stars），定位为 ** 通用记忆层 ** ——任何 AI 应用都可以接入。有托管平台和开源自托管两种部署方式。

四层记忆架构

层级 作用 生命周期 ** Conversation Memory ** 当前对话轮次内的消息 轮次结束即失效 ** Session Memory ** 单次任务/会话的短期事实 会话结束即失效 ** User Memory ** 跨会话的用户级长期记忆 永久（用户维度） ** Organization Memory ** 跨用户共享的团队知识 永久（组织维度）
这四层与 CoALA 的分类精确对应：Conversation = 工作记忆，Session = 情景记忆（短期），User = 语义记忆（长期），Organization = 共享知识库。

记忆处理管线

对话消息 → add()
              ↓
         1. LLM 提取关键事实（infer=True）
         2. 冲突检测与去重（与已有记忆比较）
         3. 存储到向量数据库 + 可选图数据库
              ↓
检索时 → search(query) → 向量检索 + 可选 Reranker → 排序返回

** 三个关键步骤 ** ： ** 提取 ** ：LLM 从消息中提取关键事实、偏好、决策 ** 冲突解决 ** ：检查已有记忆，去重/更新，保证"最新真相" ** 存储 ** ：向量存储 + 可选 Graph 存储（实体关系）

检索增强

能力 说明 ** 语义搜索 ** 基于 embedding 的相似度检索 ** 元数据过滤 ** 按 user_id、category、日期等过滤 ** Reranker ** 可配置 Cohere 等二次排序，提升精度 ** top_k / threshold ** 控制返回数量和最低相似度

可配置组件栈

Mem0 的每个组件都可替换： 组件 默认 可替换为 LLM OpenAI gpt-5-mini Azure OpenAI, Anthropic, Gemini, Ollama Embedder OpenAI text-embedding-3-small VertexAI, Ollama Vector Store Qdrant (本地) Postgres+pgvector, Elasticsearch, Milvus, Chroma Reranker 无 Cohere, Zero Entropy

托管 vs 开源

维度 Mem0 Platform Mem0 OSS 部署 全托管 SaaS 自托管（Python 库 / Docker） 图记忆 ✅ 内置 ❌ 需自建 Dashboard ✅ 托管控台 ✅ 自托管控台 扩展性 自动扩缩 手动管理 合规 SOC 2, GDPR 自行负责

LlamaIndex：Memory Block 组合式架构

** 核心设计 ** ：短期记忆（FIFO 队列）+ 可组合的长期记忆块（Memory Block）。

记忆流转机制

对话消息 → 短期记忆（FIFO）
              ↓ 超过 token 限制时 flush
         长期记忆块（Memory Block）
              ↓ 检索时合并
         短期 + 长期 → 注入 Prompt

** 关键参数 ** ： token_limit （默认 30000）：短期+长期的总 token 上限 chat_history_token_ratio （默认 0.7）：短期记忆占比，超出时 flush 到长期记忆 token_flush_size （默认 3000）：每次 flush 的 token 数

三种预置 Memory Block

Block 功能 适用场景 ** StaticMemoryBlock ** 存储固定的核心信息 "用户偏好暗色主题" ** FactExtractionMemoryBlock ** LLM 自动提取事实 从对话中提取关键事实，max_facts=50 ** VectorMemoryBlock ** 向量数据库存储/检索 基于相似度检索历史消息批次
** Priority 截断机制 ** ：priority=0 永远保留，priority 越大越先被截断。这保证了核心信息不丢失。
** 远程存储 ** ：默认使用内存 SQLite，可配置 PostgreSQL 等远程数据库。

Spring AI：Repository 抽象 + 滑动窗口

** 核心设计 ** ：ChatMemory（策略）+ ChatMemoryRepository（存储），策略与存储解耦。

ChatClient → Advisor → ChatMemory → ChatMemoryRepository → Database

** 唯一策略 ** ：MessageWindowChatMemory——滑动窗口，保留最近 N 条消息（默认 20），系统消息始终保留。
** 丰富的存储后端 ** （6 种）：JDBC（PostgreSQL/MySQL/Oracle/SQL Server）、Cassandra（TTL 自动过期）、Neo4j（图存储）、CosmosDB（全球分布）、MongoDB。
** Chat Memory vs Chat History ** ：Spring AI 明确区分——Chat Memory 是 LLM 需要的上下文（滑动窗口），Chat History 是完整对话记录（建议用 Spring Data 自行管理）。

四个框架对比

维度 LangGraph Mem0 LlamaIndex Spring AI 短期记忆 Checkpointer（多后端） Conversation + Session FIFO + token flush MessageWindow（N=20） 长期记忆 Store（namespace + 语义搜索） User + Org（向量+图） Memory Block（可组合） 无（需自建） 摘要压缩 ✅ SummarizationNode ✅ LLM 自动提取 ✅ FactExtractionMemoryBlock ❌ 向量检索 ✅ Store.search(query) ✅ 语义+元数据+Reranker ✅ VectorMemoryBlock ❌（需自建） 图记忆 ❌ ✅ 可选 Graph ❌ ❌ 冲突检测 ❌ ✅ 自动去重/更新 ❌ ❌ 时间旅行 ✅ checkpoint 回滚 ❌ ❌ ❌ 自定义扩展 Store namespace 组件全可替换 Memory Block 子类 ChatMemoryRepository 远程存储 Postgres/Mongo/Redis Postgres/Qdrant/Milvus PostgreSQL + 向量数据库 6 种关系型+NoSQL 企业适配 框架层 独立记忆服务 Python 生态 Spring 生态原生集成

设计模式

从以上所有实现中，提炼出  ** 9 个核心设计模式 ** ：

模式 1：冻结快照（Hermes）

会话启动时注入记忆，会话内不变。保护 prefix cache，优化性能和成本。
→  ** 适用 ** ：高频调用、对延迟敏感的场景

模式 2：自动巩固（OpenClaw Dreaming）

多维度评分 + 多门控，只有反复验证的信息才晋升为长期记忆。
→  ** 适用 ** ：长期运行的个人 Agent，记忆不断增长

模式 3：双层存储（LangGraph）

Checkpointer 管 thread 内历史，Store 管跨 thread 事实。对话历史和事实记忆分离。
→  ** 适用 ** ：多租户 Agent 平台

模式 4：Repository 抽象（Spring AI）

策略（保留什么）与存储（存到哪里）解耦。简单但扩展性强。
→  ** 适用 ** ：企业级多数据库环境

模式 5：分层加载（OpenViking）

L0 (~100 tokens) 摘要 → L1 (~2k) 概览 → L2 全文，按需加载。
→  ** 适用 ** ：记忆量大但上下文窗口有限

模式 6：上下文围栏（Supermemory）

自动剥离记忆内容的指令性，只保留事实性，防止记忆污染 Agent 推理。
→  ** 适用 ** ：多来源记忆注入的安全场景

模式 7：Graph RAG（Mem0 / Hindsight）

自动提取实体关系，维护时序知识图谱。不只是记住事实，还理解事实之间的关系和演变。
→  ** 适用 ** ：复杂实体关系、需要时间线理解的场景

模式 8：规则模板化（阿里云百炼）

不硬编码提取逻辑，而是通过可配置的规则模板定义"提取什么、怎么提取、保留多久"。非技术人员也能通过控制台配置。
→  ** 适用 ** ：将记忆能力从开发者工具升级为产品能力

模式 9：通用记忆管线（Mem0）

提取→冲突检测→存储的三步管线，每个组件可替换。记忆不只是存，更重要的是提炼和去重。
→  ** 适用 ** ：任何需要接入记忆能力的 AI 应用

选型建议

你在选个人 Agent 产品

** OpenClaw ** ：自动巩固 + memory-wiki，适合"不想手动管理记忆"的用户 ** Hermes ** ：严格容量管理 + 安全扫描 + 8种 Provider，适合对隐私和性能敏感的用户

你在选开发框架构建 Agent

** Mem0 ** ：通用记忆引擎，开箱即用，适合需要快速接入记忆能力的任何 AI 应用 ** LangGraph ** ：双层存储 + 语义搜索 + 时间旅行，功能最全，适合构建多租户平台 ** LlamaIndex ** ：Memory Block 组合式架构，灵活可扩展，适合需要定制记忆逻辑的场景 ** Spring AI ** ：Repository 抽象 + Spring 生态无缝集成，但只有短期记忆，长期记忆需自建

你在选云服务级记忆方案

** 阿里云百炼记忆库 ** ：开箱即用的 Memory + Profile 双通道，适合不想自建记忆系统的团队

你在构建智能体平台

推荐组合： ** LangGraph 的双层存储思路 ** ：History 和 Memory 分离 ** OpenClaw Dreaming 的评分巩固 ** （ACE 三角色的离线实现）：自动化从 History 提炼 Memory ** Hermes 的安全扫描 ** ：记忆注入前检测 injection ** Graph RAG 的知识图谱 ** ：维护实体关系和时间线（适合复杂实体关系的场景） ** Mem0 的记忆管线 ** ：提取→冲突检测→存储的三步管线，是记忆写入的参考实现 ** Spring AI 的 Repository 抽象 ** ：存储后端可替换 ** CoALA 的记忆分类 ** ：区分语义/情景/程序性记忆，不同类型用不同策略管理 ** ACE 的 User Memory vs Agent Memory ** ：明确记忆的服务对象 ** 阿里云百炼的规则模板化 ** ：将记忆提取逻辑做成可配置的规则模板，支持产品化落地

记忆更新时机（来自 ACE）

时机 优点 缺点 ** 实时更新 ** （Hot Path） 不丢信息 影响主流程响应延迟 ** 异步更新 ** （Background） 不阻塞主流程 记忆更新有延迟 ** 用户触发 ** （点赞/收藏） 高信号质量 依赖用户主动行为
实践中推荐： ** 异步更新为主 ** （后台定时提取）， ** 实时更新为辅 ** （关键事实立即写入）， ** 用户触发 ** 作为高置信度信号来源。

参考来源

Hermes Agent Memory: https://hermes-agent.nousresearch.com/docs/user-guide/features/memory Hermes Memory Providers: https://hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers OpenClaw Memory: https://docs.openclaw.ai/concepts/memory LangChain Memory Concepts: https://docs.langchain.com/oss/python/concepts/memory LangGraph Add Memory: https://docs.langchain.com/oss/python/langgraph/add-memory Spring AI Chat Memory: https://docs.spring.io/spring-ai/reference/api/chat-memory.html LlamaIndex Memory: https://developers.llamaindex.ai/python/framework/module_guides/deploying/agents/memory/ Mem0 Platform: https://docs.mem0.ai/platform/overview Mem0 Open Source: https://docs.mem0.ai/open-source/overview Mem0 Memory Types: https://docs.mem0.ai/core-concepts/memory-types 扣子长期记忆: https://docs.coze.cn/guides/long_memory 阿里云百炼记忆库: https://help.aliyun.com/zh/model-studio/memory-library 阿里云百炼长期记忆 API: https://help.aliyun.com/zh/model-studio/long-term-memory-api-reference CoALA Paper: https://arxiv.org/pdf/2309.02427 ACE Paper: https://www.arxiv.org/abs/2510.04618